feat(phase-2): refine sql select options#217
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: edcf1a7530
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| fn validate_scan_range_args(args: &SqlArgs) -> std::result::Result<(), String> { | ||
| if args.scan_start.is_none() && args.scan_end.is_none() { | ||
| return Ok(()); | ||
| } | ||
| if matches!(args.input_format, InputFormatArg::Parquet) { | ||
| return Err("ScanRange is not supported for Parquet input".to_string()); |
There was a problem hiding this comment.
When a user supplies --scan-start or --scan-end together with --compression gzip/bzip2 on CSV or JSON input, this validator lets the command proceed and the S3 layer attaches ScanRange to a compressed-object request. The AWS S3 Select user guide states that for scan range requests, “CSV and JSON objects must be uncompressed” (see https://docs.aws.amazon.com/AmazonS3/latest/userguide/selecting-content-from-objects.html#selecting-content-from-objects-scan-range), so these combinations fail at the backend instead of being reported as the intended usage error before sending the request.
Useful? React with 👍 / 👎.
2 participants
Related issue(s)
None.
Background
The rc sql command gained broader S3 Select serialization options, but a few exposed paths did not match RustFS behavior closely enough. In particular, progress events were requested but not surfaced to users, and several RustFS-invalid argument combinations were only rejected by the backend.
Solution
Test status